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OPEN  SYSTEMS  POLICY  HIGHLIGHTS 


i.  Introduction 

The  purpose  of  this  document  is  to  provide  readers  with  a  quick  reference  and  better  understanding  of 
scope  and  content  of  open  system  policy  language  in  the  DoD  5000  series  documents.  These  policy 
directions  have  been  promulgated  in  May  12,  2003  revision  of  the  DoD  Directive  5000.1,  the  DoD 
Instruction  5000.2  “Operation  of  the  Defense  Acquisition  System,”  and  the  subsequent  canceling  of  the 
DoD  5000. 2-R,  “Mandatory  Procedures  for  Major  Defense  Acquisition  Programs  and  Major  Automated 
Information  Systems  Acquisition  Programs”  and  its  conversion  into  the  Interim  Defense  Acquisition 
Guidebook  (October  30,  2002). 

The  new  streamlined  policy  language  in  the  DODD  5000.1  enables  decision-makers  and  program 
managers  to  tailor  acquisition  strategies  to  fit  the  particular  conditions  of  an  individual  program.  It  also 
makes  time-phased  requirements  and  evolutionary  acquisition  strategies  the  preferred  approach  to 
establishing  and  documenting  operational  needs.  Moreover,  proposed  programs  may  enter  the  acquisition 
process  at  various  decision  points,  depending  on  concept  and  technology  maturity.  The  decision-makers, 
users,  and  program  managers  are  also  required  to  first  consider  the  procurement  of  commercially 
available  products,  services,  and  technologies,  or  the  development  of  dual-use  technologies,  to  satisfy 
user  requirements. 

The  DoD  Instruction  5000.2  is  a  new  policy  document  that  establishes  a  simplified  and  flexible 
management  framework  for  translating  mission  needs  and  technological  opportunities  into  stable, 
affordable,  and  well-managed  acquisition  programs.  It  also  establishes  a  general  approach  for  managing 
acquisition  programs  while  acknowledging  that  every  technology  project  and  acquisition  program  is 
unique  and  that  any  particular  project  or  program,  particularly  non-major  programs,  need  not  follow  the 
entire  acquisition  process.  Based  on  the  new  DoD  Instruction,  the  Defense  Acquisition  System  is  a 
continuum  composed  of  following  three  activities  with  multiple  paths  into  and  out  of  each  activity: 

■  Pre-system  acquisition  -  Technologies  are  researched,  developed,  or  procured  in  pre-system 
acquisition  (science  and  technology  and  concept  development  and  demonstration). 

■  Systems  acquisition  -  Systems  are  developed,  demonstrated,  produced  or  procured,  and  deployed 
in  systems  acquisition. 

■  Post-systems  acquisition  -  Once  deployed,  the  system  is  supported  throughout  its  operational  life 
and  eventual  disposal  in  post-systems  acquisition. 

The  Interim  Defense  Acquisition  Guidebook  is  being  completely  revised  and  the  current  Interim 
Guidebook  is  identical  to  the  cancelled  DoD  5000.2-R;  the  “Mandatory  Procedures  for  Major  Defense 
Acquisition  Programs  and  Major  Automated  Information  Systems  Acquisition  Programs.”  The  guidance 
directions  contained  in  the  Guidebook  is  compatible  with  the  newly  approved  acquisition  process  and 
instructions.  The  interim  Guidebook  will  provide  the  acquisition  workforce  with  the  best  information 
available  to  implement  the  Directive  and  Instruction  guidance 
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ii.  Specific  Directions 

The  Open  Systems  Joint  Task  Force  Task  force  has  been  able  to  insert  new  language  and  improve  the 
existing  open  systems  guidance  contained  in  DoDD  5000.1  and  the  Interim  Defense  Guidebook 
documents. 


A.  Open  System  Language  in  the  DoDD  5000.1  (approved  May  12,  2003) 

Based  on  the  new  open  systems  policy  guidance,  the  programs  are  directed  to  use  a  modular  open 
system  approach  (MOSA)  to  ensure  access  to  the  latest  technologies  and  products,  and  facilitate 
affordable  and  supportable  modernization  of  fielded  assets.  Paragraph  El. 27  titled  “Systems 
Engineering”  contain  open  systems  related  guidance  for  acquisition  decision  makers.  It  reads  as: 

“Acquisition  programs  shall  be  managed  through  the  application  of  a  systems  engineering  approach 
that  optimizes  total  system  performance  and  minimizes  total  ownership  costs.  A  modular,  open- 
systems  approach  shall  be  employed,  where  feasible.” 


The  following  paragraphs  contain  policy  language  that  indirectly  calls  for  the  application  of  MOSA 
and  will  most  cost  effectively  be  implemented  using  such  approach: 

■  Paragraph  4.3.2  Responsiveness.  Advanced  technology  shall  be  integrated  into 
producible  systems  and  deployed  in  the  shortest  time  practicable.  Approved,  time- 
phased  capability  needs  matched  with  available  technology  and  resources  enable 
evolutionary  acquisition  strategies.  Evolutionary  acquisition  strategies  are  the 
preferred  approach  to  satisfying  operational  needs.  Spiral  development  is  the 
preferred  process  for  executing  such  strategies. 


■  Paragraph  El .3  Competition.  . . .  Acquisition  managers  shall  take  all  necessary 
actions  to  promote  a  competitive  environment,  including  the  consideration  of 
alternative  systems  to  meet  stated  mission  needs;  structuring  S&T  investments  and 
acquisition  strategies  to  ensure  the  availability  of  competitive  suppliers  throughout  a 
program's  life,  and  for  future  programs;  ensuring  that  prime  contractors  foster 
effective  competition  for  major  and  critical  products  and  technologies;  . 


■  Paragraph  El .13  Interoperability.  Systems,  units,  and  forces  shall  be  able  to  provide  and 
accept  data,  information,  materiel,  and  services  to  and  from  other  systems,  units,  and  forces 
and  shall  effectively  interoperate  with  other  U.S.  Forces  and  coalition  partners.  Joint  concepts 
and  integrated  architectures  shall  be  used  to  characterize  these  interrelationships. 

■  Paragraph  El .14  Knowledge-Based  Acquisition . PMs  shall  reduce  technology 

risk,  demonstrate  technologies  in  a  relevant  environment,  and  identify  technology 
alternatives,  prior  to  program  initiation.  They  shall  reduce  integration  risk  and 
demonstrate  product  design  prior  to  the  design  readiness  review.  They  shall  reduce 
manufacturing  risk  and  demonstrate  producibility  prior  to  full-rate  production. 
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■  Paragraph  El .16  Performance-Based  Acquisition.  To  maximize  competition, 
innovation,  and  interoperability,  and  to  enable  greater  flexibility  in  capitalizing  on 
commercial  technologies  to  reduce  costs,  acquisition  managers  shall  consider  and  use 
performance-based  strategies  for  acquiring  and  sustaining  products  and  services 
whenever  feasible.  For  products,  this  includes  all  new  procurements  and  major 
modifications  and  upgrades,  as  well  as  reprocurements  of  systems,  subsystems,  and 
spares  that  are  procured  beyond  the  initial  production  contract  award.  When  using 
performance-based  strategies,  contract  requirements  shall  be  stated  in  performance 
terms,  limiting  the  use  of  military  specifications  and  standards  to  Government -unique 
requirements  only. 


■  Paragraph  El. 18  Products,  Services,  and  Technologies.  The  DoD  Component(s)  shall 
consider  multiple  concepts  and  analyze  possible  alternative  ways  to  satisfy  the  user 
need.  System  concepts  shall  be  founded  in  an  operational  context,  consistent  with  the 
National  Military  Security  Strategy,  Defense  Planning  Guidance,  Joint  Concepts,  and 
joint  integrated  architectures.  The  DoD  Components  shall  seek  the  most  cost- 
effective  solution  over  the  system's  life  cycle.  They  shall  conduct  market  research  and 
analysis  to  determine  the  availability,  suitability,  operational  supportability, 
interoperability,  safety,  and  ease  of  integration  of  the  considered  and  selected 
procurement  solutions.  The  DoD  Components  shall  work  with  users  to  define 
capability  needs  that  facilitate  the  following,  listed  in  descending  order  of  preference: 

El.  18.1  The  procurement  or  modification  of  commercially  available  products, 
services,  and  technologies,  from  domestic  or  international  sources,  or  the  development 
of  dual-use  technologies. . . 

B.  Open  System  Language  in  the  DoDI  5000.2  (approved  May  12,  2003) 

There  is  no  direct  and  specific  reference  to  open  systems  policy  guidance  in  the  Instruction.  However, 
the  indirect  language  requires  that  programs  refrain  from  early  commitments  to  system- specific 
solutions  that  inhibit  future  insertion  of  new  technology  and  commercial  or  non-developmental  items. 
The  following  paragraphs  in  the  DoDI  5000.2  contain  indirect  open  systems  related  guidance  for 
acquisition  decision-makers: 

■  Section  3.2.1  Integrated  Architectures,  Paragraph  3.2. 1.2  Military  Departments  and  Defense 
Agencies  shall  participate  in  the  identification  of  the  appropriate  technical  view  consisting  of 
standards  that  define  and  clarify  the  individual  systems  technology  and  integration  requirements. 

■  Paragraph  3.3.5.  The  ICD  and  the  AoA  plan  shall  guide  Concept  Refinement.  The  focus  of  the 
AoA  is  to  refine  the  selected  concept  documented  in  the  approved  ICD.  The  AoA  shall  assess  the 
critical  technologies  associated  with  these  concepts,  including  technology  maturity,  technical  risk, 
and,  if  necessary,  technology  maturation  and  demonstration  needs.  To  achieve  the  best  possible 
system  solution,  emphasis  shall  be  placed  on  innovation  and  competition.  Existing  commercial- 
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off-the-shelf  (COTS)  functionality  and  solutions  drawn  from  a  diversified  range  of  large  and  small 
businesses  shall  be  considered. 


C.  Open  System  Language  in  the  Interim  Defense  Acquisition  Guidebook  (approved  October  30, 
2002) 

As  mentioned  earlier,  the  open  system  policy  language  in  the  interim  Defense  Acquisition  Guidebook 
document  is  the  same  language  that  was  contained  in  the  cancelled  DoD  5000. 2-R.  The  open  systems 
language  contained  in  this  document  guides  the  PMs  to  assess  the  feasibility  of  using  widely- 
supported  commercial  interface  standards  in  developing  systems.  PMs  are  also  encouraged  to  report 
on  their  progress  using  open  standards  for  key  interfaces  at  both  Milestones  B  and  C.  Program 
managers  should  also  identify  key  interfaces  and  define  the  system  level  (system-of-systems,  system, 
subsystem,  or  component)  at  and  above  which  these  interfaces  use  various  types  of  standards.  The 
new  guidance  also  stipulates  that  the  selected  Commercial  Items  (CIs)  and  Non  Developmental  Items 
(NDIs)  have  open  interfaces  to  the  maximum  extent  practicable  and  the  risks  and  impacts  on  total 
cost  of  ownership  be  evaluated  if  products  with  closed  interfaces  are  acquired.  The  following 
paragraphs  in  the  Interim  Defense  Acquisition  Guidebook  contain  open  systems  related  guidance  for 
acquisition  decision-makers: 


■  Part  2:  Acquisition  Strategy,  Paragraph  2.7.1  titled  “Open  Systems” 

The  new  open  systems  guidance  at  this  paragraph  encourage  PMs  to  assess  the  feasibility  of  using 
widely- supported  commercial  interface  standards  in  developing  systems.  It  also  guides  PMs  to 
make  the  open  systems  approach  an  integral  part  of  the  overall  acquisition  strategy  to  enable  rapid 
acquisition  with  demonstrated  technology,  evolutionary  and  conventional  development, 
interoperability,  life-cycle  supportability,  and  incremental  system  upgradeability  without  major 
redesign  during  initial  procurement  and  reprocurement  of  systems,  subsystems,  components, 
spares,  and  services,  and  during  post-production  support.  PMs  are  also  encouraged  to  document 
their  approach  for  using  open  systems  and  include  a  summary  of  their  approach  as  part  of  their 
overall  acquisition  strategy. 


■  Part  5:  Program  Design,  Paragraph  5.2.5,  titled  "Open  Systems  Design" 

The  open  systems  guidance  in  this  paragraph  directs  PMs  to  use  a  modular,  standards-based 
architecture  in  design  of  weapons  systems.  PMs  should  identify  key  interfaces  and  define  the 
system  level  (system  of  system,  system,  subsystem,  or  component)  at  and  above  which  these 
interfaces  use  various  types  of  standards.  The  language  also  directs  PMs  to  use  open  interface 
standards  first,  then  de  facto,  and  finally  government  and  proprietary  interface  standards.  PMs  are 
also  encouraged  to  report  on  their  progress  using  open  standards  for  key  interfaces  at  both 
Milestones  B  and  C.  Based  on  the  new  open  systems  acquisition  policy  guidance,  PMs  may  use  an 
open  systems  approach  to  achieve  the  following  objectives: 

■  To  adapt  to  evolving  requirements  and  threats; 

■  To  accelerate  transition  from  science  and  technology  into  acquisition  and  deployment; 
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■  To  enhance  modularity  and  facilitate  systems  integration; 

■  To  leverage  commercial  investment  in  new  technologies  and  products; 

■  To  reduce  the  development  cycle  time  and  total  life-cycle  cost; 

■  To  ensure  the  system  is  fully  interoperable  with  all  systems  with  which  it  must  interface, 
without  major  modification  of  existing  components; 

■  To  achieve  commonality  and  reuse  of  components  among  systems; 

■  To  provide  users  the  ability  to  quickly  and  affordably  interconnect  and  assemble  existing 
platforms,  systems,  subsystems,  and  components  as  needed; 

■  To  maintain  continued  access  to  cutting  edge  technologies  and  products  from  multiple 
suppliers  during  initial  procurement,  reprocurement,  and  post-production  support; 

■  To  mitigate  the  risks  associated  with  technology  obsolescence,  being  locked  into 
proprietary  technology,  and  reliance  on  a  single  source  of  supply  over  the  life  of  a  system; 

■  To  conduct  business  case  analyses  to  justify  decisions  to  enhance  life-cycle  supportability 
and  continuously  improve  product  affordability  through  technology  insertion  during  initial 
procurement,  reprocurement,  and  post-production  support;  and 

■  To  facilitate  modular  contracting. 


■  Part  5:  Program  Design,  Paragraph  5.2  titled  “Systems  Engineering” 

The  open  systems  guidance  language  under  this  paragraph  calls  for  application  of  a  systems 
engineering  process  that  will  ensure  the  interoperability  and  integration  of  all  operational, 
functional,  and  physical  interfaces.  It  stipulates  that  iterative  requirements  analyses  accompany 
functional  analysis/allocation  to  develop  and  refine  system-level  functional  and  performance 
requirements  and  external  interfaces  to  facilitate  the  design  of  open  systems.  The  design  solutions 
are  also  required  to  be  sufficiently  detailed  to  verify  that  open  system  performance  requirements 
have  been  met.  The  iterative  functional  analyses/allocations  must  also  define  successively  lower- 
level  functional  and  performance  requirements,  including  functional  interfaces  and  architecture  to 
achieve  open  systems  and  facilitate  the  use  of  a  performance-based  business  environment.  The 
open  systems  policy  language  at  this  paragraph  also  stipulates  that  system  analysis  and  control 
activities  include  a  configuration  management  process  to  facilitate  the  development  of  open 
systems.  The  overall  risk  management  effort  must  also  include  technology  transition  planning  and 
establish  transition  criteria  and  interface  controls  to  ensure  all  internal  and  external  interface 
requirements  changes  are  properly  recorded  and  communicated  to  all  affected  configuration  items. 


■  Other  Open  Systems  Policy  Guidance  at  the  Interim  Defense  Acquisition  Guidebook 

Beside  guidance  language  in  the  above-mentioned  paragraphs,  open  systems  guidance  has  also 
been  inserted  in  the  following  paragraphs: 

■  Part  2:  Acquisition  Strategy 

■  Paragraph  2.6.3,  Integrated  Digital  Environment  (IDE) 
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■  Paragraph  2. 6. 6. 2,  Applying  Best  Practices 

■  Paragraph  2.7.2,  Interoperability 

■  Paragraph  2.8,  Support  Strategy 

■  Paragraph  2. 8. 1.1,  Product  Support  Management  Plan 

■  Paragraph  2.8.6,  Life-Cycle  Support  Oversight 

■  Paragraph  2.9. 1.2.2,  Applying  Competition  to  Evolutionary  Acquisition 

■  Paragraph  2.9. 1.3.2,  Sub-Tier  Competition 

■  Paragraph  2.9. 1 .4. 1 ,  Market  Research 

■  Paragraph  2.9. 1.4.2,  Commercial  and  Non-Develop-mental  Items 

■  Paragraph  2.9. 1.4.3,  Dual-Use  Technologies  and  the  Use  of  Commercial  Plants 
■  Part  5:  Program  Design 

■  Paragraph  5.2.6,  Software  Management 

■  Paragraph  5.2.7,  COTS  Considerations 

■  Paragraph  5.3.2,  Performance  Specifications 


